Collaboration involves the ability for each member in a group of members, called “collaborators” to automatically transmit information to, and receive information from, other collaborators in the group. In order to facilitate such collaboration, various systems have been developed that allow such information to be transmitted between personal computer systems, communication appliances or other communication devices, including handheld and wireless devices. Collectively, these devices will be referred to a “computers” in this description.
Computer-based collaboration may occur locally among users connected to, or operating with, one computer or server. Alternatively, collaboration may occur over a network, such as the Internet, wherein each of the users is located at a computer connected to the network. A server may also be connected to the network. Several collaboration models are currently being implemented as networked computer collaboration systems. One of these models is a client-server model in which all collaborators are connected, via the network, to a central server. Information generated by each collaborator is sent over the network to the server that then broadcasts the information back over the network to each other collaborator. Another model is a “peer-to-peer” model in which direct connections are established over the network between each of the collaborator computers. Information generated by each collaborator is then sent directly to each other collaborator. In such a system, the collaborators communicate in a private “virtual” shared space.
In both of these models, there are several methods by which information is transferred between collaborators. For example, in a client-server system, data that is being collaboratively modified may be stored on the server. Then, each collaborator that wants to modify the data sends a command to the server to effect a change in the server data. The server modifies its copy of the data and then sends information representing a “view” of the modified data to all collaborators, so that each collaborator can display the data locally.
A central data repository is not possible in a peer-to-peer collaboration system because no collaborator acts as a server. Thus, in such systems, each collaborator has a local copy of the data being collaboratively modified. In order to change the data, a collaborator generates a data change request that is forwarded to each other collaborator. The incoming data change requests are then used by each collaborator to modify its local data copy.
The latter type of collaboration system is described in detail in U.S. patent application Ser. No. 09/357,007 entitled METHOD AND APPARATUS FOR ACTIVITY-BASED COLLABORATION BY A COMPUTER SYSTEM EQUIPPED WITH A COMMUNICATIONS MANAGER, filed Jul. 19, 1999 by Raymond E. Ozzie, Kenneth G. Moore, Robert H. Myhill and Brian M. Lambert; U.S. patent application Ser. No. 09/356,930 entitled METHOD AND APPARATUS FOR ACTIVITY-BASED COLLABORATION BY A COMPUTER SYSTEM EQUIPPED WITH A DYNAMICS MANAGER, filed Jul. 19, 1999 by Raymond E. Ozzie and Jack E. Ozzie; U.S. patent application Ser. No. 09/356,148 entitled METHOD AND APPARATUS FOR PRIORITIZING DATA CHANGE REQUESTS AND MAINTAINING DATA CONSISTENCY IN A DISTRIBUTED COMPUTER SYSTEM EQUIPPED FOR ACTIVITY-BASED COLLABORATION, filed Jul. 19, 1999 by Raymond E. Ozzie and Jack E. Ozzie and U.S. patent application Ser. No. 09/588,195 entitled METHOD AND APPARATUS FOR EFFICIENT MANAGEMENT OF XML DOCUMENTS, filed Jun. 6, 2000 by Raymond E. Ozzie, Kenneth G. Moore, Ransom L. Richardson and Edward J. Fischer.
In this collaboration system, each collaborator has a program called an “activity”, that is operable in his or her computer. The activity program contains a tool that responds to user interactions by generating data change commands. These data change commands are provided to a data-change engine that maintains the local data copy by performing the changes to the data requested by the data change commands. The commands are inserted into a container called a “delta” and deltas are distributed from one collaborator to another by a program called a communications manager.
When a peer-to-peer collaboration system is used over a network, special considerations must be addressed. A major consideration is network latency. In particular, when a delta is transmitted over the network to a group of other collaborators, it may reach some collaborators sooner than others due to unequal transit times over the network. Since all collaborators send and receive deltas “asynchronously”, the requests may be received by different collaborators in different orders. This can potentially create a problem because the correct execution of some commands may depend on other commands having been previously executed. In order to ensure that the local data copies remain consistent, the collaboration system must preserve causality. Specifically, causality demands that, when a current data change command received from a first collaborator is executed by a second collaborator, the second collaborator will have executed all previous data change commands that the first collaborator had executed when the current data change command was created.
Another condition that must be satisfied is convergence. Convergence ensures that when all collaborators have executed the same set of operations, the final execution order of data change commands by all collaborators is the same. In the collaboration system described in the aforementioned patent applications, a special program in each computer called a dynamics manager receives and interprets the deltas generated in that computer and received by that computer from other computers in order to preserve causality and to ensure convergence.
Another potential problem in a peer-to-peer system concerns collaborators entering and leaving the collaboration group during an on-going session by disconnecting their computers from the network or powering down the computers. Since the integrity of a collaborator's local data copy depends on receiving data change commands from other collaborators and correctly interpreting these commands, collaborators who leave a collaboration session will need either a complete current copy of the local data or a collection of data change commands that were transmitted by other collaborators during their absence in order to restart their system. In many cases, the copy of the local data and the collection of data change commands can be quite large resulting in a lengthy startup delay for a collaborator entering an ongoing collaboration session.